1. Field of the Invention
The present invention relates to a wireless communications device. More particularly, the present invention relates to discriminating between the handling of a layer 2 unrecoverable error and a layer 1 radio link failure.
2. Description of the Prior Art
The 3rd Generation Partnership Project (3GPP) specifications 3GPP TS 25.331 V3.11.0 (2002–06) “Radio Resource Control (RRC) Protocol Specification” and 3GPP TS 25.322 V3.11.0 (2002–06) “Radio Link Control (RLC) protocol specification”, both of which are included herein by reference, provide technical description of a Universal Mobile Telecommunications System (UMTS). The UMTS discloses a device (typically a mobile device), termed user equipment (UE), in wireless communications with one or more base stations. These base stations (so-called Node Bs) with Radio Network Controllers (RNCs) are collectively termed the UMTS Terrestrial Radio Access Network, or UTRAN for short.
Please refer to FIG. 1. FIG. 1 is a simple block diagram of a 3GPP wireless communications network 10. The wireless communications network 10 comprises a plurality of radio network subsystems (RNSs) 20 in communications with a core network (CN) 30. The CN 30 includes a packet switch (PS) domain 30p and a circuit switch (CS) domain 30c. The plurality of RNSs 20 form a UTRAN 20u. Each RNS 20 comprises one RNC 22 that is in communications with a plurality of Node Bs 24. Each Node B 24 is a transceiver, which is adapted to send and receive wireless signals, and which defines a cell region. A number of cells (i.e., a number of Node Bs 24) taken together defines a UTRAN Registration Area (URA). In particular, the wireless communications network 10 assigns a UE 40 to a particular RNS 20, which is then termed the serving RNS (SRNS) 20s of the UE 40. Data destined for the UE 40 is sent by the CN 30 (or UTRAN 20u) to the SRNS 20s. It is convenient to think of this data as being sent in the form of one or more packets that have a specific data structure, and which travel along one of a plurality of radio bearers (RBs) 28, 48. An RB 48 established on the UE 40 will have a corresponding RB 28 established on the UE SRNS 20s. The RBs are numbered consecutively, from RB0 to RBn. Typically, RB0 to RB4 are dedicated signaling RBs (SRBs), which are used for passing protocol signals between the UTRAN 20u and the UE 40, and will be described in some more detail below. RBs 28, 48 greater than four (i.e., RB5, RB6, etc.) are typically used to carry user data. The RNC 22 utilizes a Node B 24, which may be assigned to the UE 40 by way of a Cell Update procedure, to transmit data to, and receive data from, the UE 40. The Cell Update procedure is initiated by the UE 40 to change a cell as defined by a Node B 24. Selection of a new cell region will depend, for example, upon the location of the UE 40 within the domain of the SRNS 20s. The UE 40 sends data to the wireless communications network 10, which is then picked up by the SRNS 20s and forwarded to the CN 30. Occasionally, the UE 40 may move close to the domain of another RNS 20, which is termed a drift RNS (DRNS) 20d. A Node B 24 of the DRNS 20d may pick up the signal transmitted by the UE 40. The RNC 22 of the DRNS 20d forwards the received signal to the SRNS 20s. The SRNS 20s uses this forwarded signal from the DRNS 20d, plus the corresponding signals from its own Node Bs 24 to generate a combined signal that is then decoded and finally processed into packet data. The SRNS 20s then forwards the received data to the CN 30. Consequently, all communications between the UE 40 and the CN 30 must pass through the SRNS 20s. 
Please refer to FIG. 2 in conjunction with FIG. 1. FIG. 2 is a simple block diagram of a UMTS radio interface protocol architecture, as used by the communications network 10. Communications between the UE 40 and the UTRAN 20u is effected through a multi-layered communications protocol that includes a layer 1, a layer 2 and a layer 3, which together provide transport for a signaling plane (C-plane) 92 and a user plane (U-plane) 94. Layer 1 is the physical layer 60, and in the UTRAN 20u is responsible for combining signals received from the DRNS 20d and SRNS 20s. Layer 2 includes a packet data convergence protocol (PDCP) layer 70, a Radio Link Control (RLC) layer 72, and a Medium Access Control (MAC) layer 74. Layer 3 includes a Radio Resource Control (RRC) layer 80. The U-plane 94 handles user data transport between the UE 40 and the UTRAN 20u (RBs 28, 48 from five and upwards), whereas the C-plane 92 handles transport for signaling data between the UE 40 and the UTRAN 20u (RBs 28, 48 from zero to four). The RRC 80 sets up and configures all RBs 28, 48 between the UTRAN 20u and the UE 40. The PDCP layer 22 provides header compression for Service Data Units (SDUs) received from the U-plane 94. The RLC layer 72 provides segmentation of PDCP 70 SDUs and RRC 80 SDUs into RLC protocol data units (PDUs). The RLC layer 72 is composed of one or more RLC entities 76. Each RLC entity 76 is individually associated with an RB 28, 48. For an RB 28 on the UTRAN 20u side, there exists an RLC entity 76 dedicated solely to that RB 28. For the same RB 48 on the UE 40 side, there similarly exists a corresponding RLC entity 76. These two corresponding RLC entities 76 for the same RB 28, 48 are termed “RLC peer entities”. Under acknowledged mode (AM) transfers, the RLC layer 72 can provide upper layers (such as the PDCP layer 70 or the RRC layer 80) with a confirmation that RLC PDUs have been successfully transmitted and received between the RLC peer entities 76 on the UTRAN 20u and the UE 40. The MAC layer 74 provides scheduling and multiplexing of RLC PDUs onto the transport channel, interfacing with the physical layer 60.
Please refer to FIG. 3 with reference to FIG. 1 and FIG. 2. FIG. 3 is a state diagram of the RRC layer 80. The RRC layer 80 has two primary states: an idle mode 81 and a UTRA RRC Connected Mode 86. While in idle mode, the RRC layer 80 has no lines of communication open with its peer RRC layer 80. That is, there are no available SRBs 28, 48 that enable communications between peer entity RRC layers 80, except for RB0, which is a common channel available to all UEs 40 in the UTRAN 20u. Utilizing the UE 40 as an example platform, once the RRC layer 80 of the UE 40 establishes a connection (i.e., SRBs 28, 48 from one to four) with its peer RRC layer 80 on the UTRAN 20u, the RRC layer 80 of the UE 40 switches into the UTRA RRC Connected Mode 86. This connection is typically initiated along RB0, which is a shared channel. Internally, the UTRA RRC Connected Mode 86 has four unique states: CELL_DCH 82, CELL_FACH 83, CELL_PCH 84 and URA_PCH 85. The CELL_DCH state 82 is characterized in that a dedicated channel is allocated to the UE 40 for uplink (UE 40 to UTRAN 20u) and downlink (UTRAN 20u to UE 40) communications. The CELL_FACH state 83 is characterized in that no dedicated channel is allocated to the UE 40, but instead the UE 40 is assigned a default common or shared transport channel for uplink. The CELL_PCH state 84 is characterized in that no dedicated physical channel is allocated to the UE 40, no uplink activity is possible for the UE 40, and the position of the UE 40 is known by the UTRAN 20u on a cell level (i.e., a node B basis 24). The URA_PCH state 85 is characterized in that no dedicated physical channel is allocated to the UE 40, no uplink activity is possible for the UE 40, and the position of the UE 40 is known by the UTRAN 20u on a URA basis.
A number of reconfiguration procedures are available to the RRC layer 80 to setup and configure RBs 28, 48. These procedures involve the UTRAN 20u sending a specific message to the UE 40 along an RB 28, 48 in the C-plane 92, and the UE 40 responding in turn with a corresponding message, also along the C-plane 92. Typically, the message is sent along RB2. The messages include Radio Bearer Setup, Radio Bearer Reconfiguration, Radio Bearer Release, Transport Channel Reconfiguration and Physical Channel Reconfiguration, as indicated in the above-indicated 3GPP specification TS 25.331, subclause 8.2.2. For each of these reconfiguration messages, the UE 40 has a corresponding “Complete” or “Failure” response message indicating success or failure of the procedure on the UE 40 side, and which may provide the UTRAN 20u any necessary information for the UTRAN 20u to complete the procedure. The reconfiguration message and the response message may all carry optional information elements (IEs), which are fields of data that hold ancillary information. In addition to these reconfiguration procedures, there also exists a Cell Update procedure, which originates with a Cell Update message from the UE 40 and which is responded to by the UTRAN 20u. The Cell Update procedure is used by the UE 40 to indicate a change of cell location (i.e., Node B 24), of connection state 82, 83, 84, 85, and is also used to indicate radio link (RL) failures and RLC unrecoverable errors. An RL failure is a connection failure that occurs in the physical layer, i.e., in layer 160. An RLC unrecoverable error occurs in the RLC layer 72, and may have many causes.
For AM connections, when a sender RLC entity 76 detects one of the following situations, it shall senda RESET PDU to its peer RLC entity 76 to reset these two RLC peer entities 76:
1)“No_Discard after MaxDAT number of retransmissions” is configured and VT(DAT) equals the value MaxDAT (see subclause 9.7.3.4 of TS 25.322);
2)VT(MRW) equals the value MaxMRW;
3)A STATUS PDU including “erroneous Sequence Number” is received (see clause 10 of TS 25.322);                stop transmitting any AMD PDU or STATUS PDU;        increment VT(RST) by 1;        if VT(RST)=MaxRST:        the Sender may submit to the lower layer a RESET PDU;        perform the actions specified in subclause 11.4.4a of TS 25.322.        else (if VT(RST)<MaxRST):        submit a RESET PDU to the lower layer;        start the timer Timer_RST.        
Please refer to subclause 11.4 of the above-indicated 3GPP specification TS 25.322 for more details. When the maximum number of attempts to send a RESET PDU is reached, the sender RLC entity 76 shall terminate the on-going RLC RESET procedure and indicate an unrecoverable error to the upper layer (RRC layer 80).Whenthe RRC layer 80 receives the indicated unrecoverable error from the AM RLC entity 76, the UE 40 shall perform a Cell Update procedure using the cause “RLC unrecoverable error”, i.e. the UE 40 shall send a CELL UPDATE message with an IE “AM_RLC error indication (RB2, RB3 or RB4)” or “AM_RLC error indication (RB>4)” set to “TRUE” to indicate the RLC unrecoverable errorhasoccurred in control plane 92 or in the user plane 94. Please refer to TS 25.331, subclause 8.3.1 for more details of the Cell Update procedure, which is discussed briefly in the following.
For an RLC unrecoverable error in the user plane 94, after reception of a CELL UPDATE/URA UPDATE message from UE 40, the UTRAN20u should optionally include the IE “RLC re-establish indicator (RB5 and upwards)” in the CELL UPDATE CONFIRM message to request an RLC re-establishment procedure in the UE 40, in which case the corresponding RLC entities 76 should also be re-established in UTRAN 20u. 
For an RLC unrecoverable error in the control plane 92, after reception of a CELL UPDATE/URA UPDATE message from UE 40, the UTRAN20u should optionally include the IE “RLC re-establish indicator (RB2, RB3 and RB4)” in the CELL UPDATE CONFIRM message to request an RLC re-establishment procedure in the UE 40, in which case the corresponding RLC entities 76 should also be re-established in UTRAN 20u, or initiate an RRC connection release procedure by transmitting an RRC CONNECTION RELEASE message on the downlink CCCH.
If an RL failure or an RLC unrecoverable errortakes place on a dedicated channel (i.e. the RRC layer 80 is in the CELL_DCH state 82), before sending a CELL UPDATE message, the UE 40 shouldperform radio access bearer (RAB) release steps, and then select a suitable cell 24. The RAB release steps release the RABs for which the associated timer T314/T315 is equal to zero.A RAB can comprise one or more RBs, but normally there is a one-to-one relationship between RABs and RBs. While performing the RLC re-establishment procedure, if eithertimer T314 or T315 expires, the UE 40 should also release the RABs associated with the expired timer. Instructions as given by subclause 8.3.1.2 of TS 25.331, as relates to the above, are provided below. All subclauses indicated in the steps below are from TS 25.331.
When initiating the URA update or cell update procedure, the UE shall:
1>stop timer T305;
1>if the UE isin CELL_DCH state:
2>Perform RAB release steps;
1>set the variables PROTOCOL_ERROR_INDICATOR, FAILURE_INDICATOR, UNSUPPORTED_CONFIGURATION and INVALID_CONFIGURATION to FALSE;
1>set the variable CELL_UPDATE_STARTED to TRUE;
1>if the UE is not already in CELL_FACH state:
2>move to CELL_FACH state;
2>select PRACH according to subclause 8.5.17;
2>select Secondary CCPCH according to subclause 8.5.19;
2>use the transport format set given in system information as specified in subclause 8.6.5.1.
1>if the UE performs cell re-selection:
2>clear the variable C_RNTI; and
2>stop using that C_RNTI just cleared from the variable C_RNTI in MAC.
1>set CFN in relation to SFN of current cell according to subclause 8.5.15;
1>in case of a cell update procedure:
2>set the contents of the CELL UPDATE message according to subclause 8.3.1.3;
2>submit the CELL UPDATE message for transmission on the uplink CCCH.
1>in case of a URA update procedure:
2>set the contents of the URA UPDATE message according to subclause 8.3.1.3;
2>submit the URA UPDATE message for transmission on the uplink CCCH.
1>set counter V302 to 1;
1>start timer T302 when the MAC layer indicates success or failure in transmitting the message.
The prior art RAB release steps are given below. Again, subclauses mentioned in the steps below are from TS 25.331.
For the RAB release steps, the UE shall:
2>in the variable RB_TIMER_INDICATOR, set the IE “T314 expired” and the IE “T315 expired” to FALSE;
2>if the stored values of the timer T314 and timer T315 are both equal to zero; or
2>if the stored value of the timer T314 is equal to zero and there are no radio bearers associated with any radio access bearers for which in the variable ESTABLISHED_RABS the value of the IE “Re-establishment timer” is set to “useT315”:
3>release all its radio resources;
3>indicate release (abort) of the established signalling connections (as stored in the variable ESTABLISHED_SIGNALLING_CONNECTIONS) and established radio access bearers (as stored in the variable ESTABLISHED_RABS) to upper layers;
3>clear the variable ESTABLISHED_SIGNALLING_CONNECTIONS;
3>clear the variable ESTABLISHED_RABS;
3>enter idle mode;
3>perform other actions when entering idle mode from connected mode as specified in subclause 8.5.2;
3>and the procedure ends.
2>if the stored value of the timer T314 is equal to zero:
3>release all radio bearers, associated with any radio access bearers for which in the variable ESTABLISHED_RABS the value of the IE “Re-establishment timer” is set to “useT314”;
3>in the variable RB_TIMER_INDICATOR set the IE “T314 expired” to TRUE.
2>if the stored value of the timer T315 is equal to zero:
3>release all radio bearers associated with any radio access bearers for which in the variable ESTABLISHED_RABS the value of the IE “Re-establishment timer” is set to “useT315”;
3>in the variable RB_TIMER_INDICATOR set the IE “T315 expired” to TRUE.
2>if the stored value of the timer T314 is greater than zero:
3>if there are radio bearers associated with any radio access bearers for which in the variable ESTABLISHED_RABS the value of the IE “Re-establishment timer” is set to “useT314”:
4>start timer T314.
3>if there are no radio bearers associated with any radio access bearers for which in the variable ESTABLISHED_RABS the value of the IE “Re-establishment timer” is set to “useT314” or “useT315”:
4>start timer T314.
2>if the stored value of the timer T315 is greater than zero:
3>if there are radio bearers associated with any radio access bearers for which in the variable ESTABLISHED_RABS the value of the IE “Re-establishment timer” is set to “useT315”:
4>start timer T315.
2>for the released radio bearer(s):
3>delete the information about the radio bearer from the variable ESTABLISHED_RABS;
3>when all radio bearers belonging to the same radio access bearer have been released:
4>indicate local end release of the radio access bearer to upper layers using the CN domain identity together with the RAB identity stored in the variable ESTABLISHED_RABS;
4>delete all information about the radio access bearer from the variable ESTABLISHED_RABS.
2>select a suitable UTRA cell according to [4];
2>set the variable ORDERED_RECONFIGURATION to FALSE.
For example, if the stored value of the timer T314 is equal to zero and the stored value of the timer T315 is greater than zero, then the UE 40 shouldrelease locally all radio bearers 48 which are associated with any radio access bearers for which in the variable ESTABLISHED_RABS the value of the IE “Re-establishment timer” is set to “useT314”, andstart timer T315. If timer T315 expires, the UE 40 should also release locally all radio bearers 48 which are associated with any radio access bearers for which in the variable ESTABLISHED_RABS the value of the IE “Re-establishment timer” is set to “use T315”, and enter idle mode 81.
The prior art UE40, as detailed in TS 25.331, subclause 8.3.1.2, treats the cases of both RL failure and RLC unrecoverable error while the RRC 80 is in theCELL_DCH state 82 inthe same manner. That is, both error conditions while in the CELL_DCH state 82 will lead to the execution of the RAB release steps. However, RL failures and RLC unrecoverable errors have some essential differences.For example, an RLC unrecoverable error can be potentially “fixed” by returning to initial conditions by way of an RLC re-establishment procedure.An RL failure cannot, however, be “fixed” by a re-establishment procedure, as it is fundamentally a physical problem with the radio connection. Therefore, the usage of the timers T314 and T315 for RLC unrecoverable errors(as performed by the RAB release steps) on a dedicated channel is unwarranted, and may lead to some normally-functioning RABs (i.e. services or applications) being released before the RLC is re-established if the timers T314/T315 are shorter than the time required to perform the RLC re-establishment procedure.
By way of example, consider the situation in which the UE 40 is in the CELL_DCH state 82, and has U-plane 94 RABs 6 to 10 that comprise RBs 486 to 10 with a one-to-one mapping. Furtherassume that the timer T314 is set to zero seconds, and that the timer T315 is set to 10 seconds, and that all RABs except RABs 6 and 7 are associated with T314. If an RLC unrecoverable error occurs only on RB 6, the UE 40 sends a CELL UPDATE message with the IE “AM_RLC error indication (RB>4)” set to “TRUE” to the UTRAN 20u. The UTRAN 20u responds with a CELL UPDATE CONFIRM message that includes the IE “RLC re-establish indicator (RB5 and upwards)” to request a RLC re-establishment for all RABs 6 to 10 in the UE 40. The RABs 8,9 and 10 (i.e. RB 8,9 and 10) that are running correctly will be released before re-establishment is completed, since the timer T314 (at zero seconds) is shorter than the time required to perform the RLC re-establishment procedure. The malfunctioning RB 6 (i.e. RAB 6)is restored to operational order after performing the RLC re-establishment procedure, but the correctly functioning RBs 8,9 and 10 (i.e. RABs 8,9,10) are released before performing the RLC re-establishment procedure. The unnecessary release of correctly functioning RABs (i.e. services or applications) by the RAB release steps leads to areduction in the radio utilization capacity, and increases the services drop rate, which is a great inconvenience to the user of the UE 40.
Finally, according to subclause 8.3.1.6 of TS 25.331, the UE 40 shall handle both the IE “RLC re-establish indicator (RB2, RB3 and RB4)” and IE “RLC re-establish indicator (RB5 and upwards)” if received in the CELL UPDATE CONFIRM message. However, according to subclause 8.3.1.5 of TS 25.331, the UTRAN 20u may only include the IE “RLC re-establish indicator (RB5 and upwards)” in the CELL UP-DATE CONFIRM message. Hence, the IE “RLC re-establish indicator (RB2, RB3 and RB4)” is actually a useless procedural indicator, as it is impossible to be included in the CELL UPDATE CONFIRM message by the UTRAN 20u. 